<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html lang="en">
<head>
<meta name="copyright" content="Copyright (c) 2023 IBM Corporation and others. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page." >
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<meta http-equiv="Content-Style-Type" content="text/css">
<link rel="STYLESHEET" href="../../book.css" charset="ISO-8859-1" type="text/css">
<title>Incompatibilities between Eclipse JDT 4.26 and 4.27</title>
</head>
<body>
<h1>Incompatibilities between Eclipse JDT 4.26 and 4.27</h1>

<p>
  So far Eclipse did not change incompatibly between 4.26 and 4.27 in ways that affect
  plug-ins. Plug-ins that ran on 4.26 should run on 4.27 without any problems.
</p>

<!-- ############################################## -->
<h3><a name="ecj_split">Note about ECJ separation from JDT Core</a></h3>
<p>
  ECJ (Eclipse compiler for Java) code is moved from <code>org.eclipse.jdt.core</code>
  to dedicated <code>org.eclipse.jdt.core.compiler.batch</code> bundle and will be
  deployed as a separated bundle.
  The <code>org.eclipse.jdt.core.compiler.batch</code> is now included in SDK
  as a regular Eclipse bundle and can be compiled / deployed / used separately
  from <code>org.eclipse.jdt.core</code> bundle.
  All of ECJ packages are re-exported by <code>org.eclipse.jdt.core</code>, therefore
  from OSGI point of view, all 3rd party code that used some compiler related API 
  from <code>org.eclipse.jdt.core</code> doesn't require any change.
  The <code>org.eclipse.jdt.core.compiler.batch</code> bundle itself doesn't have any dependencies
  and so can be used in Eclipse products that do not use workspace concepts.
</p>
<p>
  However, no change is without side effects.
</p>
<p>
  <b>Known problems with the split of the ECJ from core bundle</b>
</p>
<ol>
  <li>
  As part of the <code>org.eclipse.jdt.core.compiler.batch</code> code separation from 
  <code>org.eclipse.jdt.core</code>, the two fragments of <code>org.eclipse.jdt.core</code> - 
  <code>org.eclipse.jdt.compiler.apt</code> and <code>org.eclipse.jdt.compiler.tool</code>
  were merged into <code>org.eclipse.jdt.core.compiler.batch</code>.
  So if some target definition, launch configuration or build file referenced the two fragments, these
  references can and should be removed now.
  </li>
  <li>
  Another issue might affect standalone (non OSGI based) applications that
  were using <code>org.eclipse.jdt.core</code> as a "simple" Java library 
  (which jdt.core never was).
  So for example code that had <code>org.eclipse.jdt.core_XYZ.jar</code> on 
  classpath and tried to call this outside Eclipse:
  <pre>ASTParser parser = ASTParser.newParser(AST.getJLSLatest());</pre>
  would fail now with <pre>NoClassDefFoundError: org.eclipse.jdt.internal.compiler.env.ICompilationUnit</pre> 
  because <code>org.eclipse.jdt.core.dom.ASTParser</code> uses internally ECJ 
  APIs and they are now ... surprise ... moved to <code>org.eclipse.jdt.core.compiler.batch</code>
  jar. To fix this error, <code>org.eclipse.jdt.core.compiler.batch</code> library
  should be added to the application classpath.
  </li>
</ol>
<!-- ############################################## -->

</body>
</html>
